Jetfire Code Life Cycle
The life cycle of a Jetfire Code Class is displayed in the following picture.
The steps include:
- Write the code
- Parse the code into an Expression Tree
- Run the code in the .net Framework Common Language Run-time environment
- Change the code in a Visual Designer
In designing the Jetfire language, we started with the programmatic model. This allows us to write unit tests against the code base to ensure that the design does not stray. Once the programmatic model was mature, we introduced a visual designer for simple workflows, such as Poll, Quiz and simple Forms.
Workflow Versioning
Software changes because improvements are introduced into the code.
There are 2 fundamental reasons for changing Jetfire code.
- The improvements introduced into the code represent better code so the old code is replaced by the new code.
- The improvements introduced into the code map into a process improvement cycle. The old process still exists, but is only used to manage objects created from the old process.
The initial purpose of Jetfire was to support process improvement cycles as defined by ISO.
E.g. we are building a first generation product according to Process X. The products ship. Based on feedback from customers or changes in procurement, we discover some root causes that will alleviate customer issues and/or accommodate new procurement practices and build improvements into Process X, now called Process X version 1. At an agreed upon date, new products are built according to Process X version 1.
How does Jetfire relate to this example? Process X and Process X version 1 are Jetfire code, i.e. we call it 'tooling the process'. The 'products' are Jetfire workflows that are created when a user clicks a link that maps to creating a new workflow.
In general, users tend to want to use the latest software. However, for projects that adhere to ISO standards, it is important to use the correct process for each release. Within each release, there are different steps involved in managing the project. These steps are workflows. Jetfire allows each release to manage again a set of different processes.
Jetfire User
In general, the user does not notice that there are different versions of code. The exception is when the user works in an ISO environment with Jetfire workflows.
Workflow Designer
The Workflow Designer is the person who writes Jetfire applications, comprised of Jetfire code. If the Jetfire workflows are being upgraded to the new code, then the Workflow Designer must follow the rules outlined in
Workflow Upgrades and Versioning.
Jetfire Administrator
The Jetfire Administrator is responsible for upgrading workflows and making sure that website pages present the workflows correctly. The
Jetfire Upgrade Workflows Web Part is used to upgrade workflows in a one-click step.
If Jetfire Workflows are used for managing multiple processes, then the Jetfire Administrator must also ensure that previous versions of Workflows can be viewed on the website.